The present invention relates generally to a virtual memory subsystem and more specifically to the representation of textures in a virtual memory space.
In many three-dimensional (3D) graphics applications, texture is used to model surface features of an object. A texture can be used to represent attributes that may vary across a surface, e.g., color, brightness, surface normal, transparency, reflectivity, and the like. Once a texture is defined, the texture may be mapped to any three-dimensional object, e.g., by associating texture coordinates with each vertex of the object and interpolating to determine texture coordinates for points between the vertices. The texture coordinates map to data values (“texels”) that represent the attribute at a particular point in the texture coordinate space. The texel for a particular point (pixel) on the surface can be used directly or blended with other information descriptive of pixel attributes (including other textures) to generate a final pixel value. For faster rendering, texture data is stored in memory local to the graphics processor, allowing the graphics processor to access the data when needed.
Achieving increased realism in rendered images involves, among other things, using larger and more complex textures to model surface features in finer detail. The texture data required often exceeds the capacity of the local memory in a graphics subsystem. Consequently, textures may need to be stored in a texture database, which is usually maintained on disk or other high-capacity storage media. However, most graphics processors cannot access data stored in such storage media without intervention by the application program (which can be triggered, e.g., using a CPU interrupt); thus, rendering operations are slowed or made impossible.
The problem of storing and accessing large textures is exacerbated in the case of mip-mapping. A mip-map is a texture map that includes multiple copies of a texture at different resolutions (levels of detail, or LOD). For instance, an initial texture of 1024×1024 texels (the highest LOD) might be filtered to 512×512, 256×256 and so on down to 1×1 (the lowest, or coarsest, LOD). When an object is rendered, texels at a level of detail commensurate with the size of the fragment in texture space are obtained by selecting the appropriate LOD map (or in some cases maps), rather than by performing filtering of large kernels on the original high-resolution texture. Mip-mapping thus reduces the need to perform filtering at runtime, at the cost of additional space required to store the mip-map. For instance, in typical mip-maps, each higher (finer) LOD has four times as many texels as the previous (coarser) LOD. Thus, the amount of memory required increases rapidly with increasing detail. Where local graphics memory is at a premium, it is often not possible to store an entire mip-map in local memory. Further, as the number of texels in a particular LOD map increases, the likelihood that all of them will be used in rendering decreases; thus, storing the entire mip-map in local memory can be wasteful.
To avoid storing the entire mip-map, “clip-map” techniques have been developed. A clip-map is a partial mip-map in which some (or all) levels of detail are clipped to a specified size. The standard, full-size mip-map is stored in a remote memory or other less expensive storage area. The clip-map, representing a subset of the complete mip-map and therefore requiring less memory, can be stored in local memory so that it can be accessed by the graphics processor. However, the clip-map is limited to representing only a single rectangular region per mip-map level; texels outside this region are only available from the remote memory. As noted above, access to the remote memory may require intervention by the application program, and such intervention may be too slow for real-time rendering.
It would therefore be desirable to provide techniques for efficient access to needed portions of texture data.